home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0330.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  2.2 KB  |  49 lines
  1.  
  2. As I understand it, the distinction between an indexed document
  3. and an ordinary one is that an indexed document is really
  4. an abstract document.   Once you provide the index terms,
  5. then it is concrete document.  So a Dictionary is abstract
  6. until I send it a keyword, then I get back a real document,
  7. the definition for the word.
  8.  
  9. In the case of the dictionary, of course, one could argue
  10. that the Dictionary as a whole is also a concrete document,
  11. since it would be possible to just read it cover to cover.
  12. On the other hand, this makes less sense if the abstract
  13. document is performing some kind of computation on the
  14. search words, for example, running finger, or even adding
  15. something to a database.  Then there is no meaningful document
  16. without the index.
  17.  
  18. If that's the right way to think, then it makes sense to put
  19. the semantics into the link, because it's more extensible.
  20. In the case of the index, the user is prompted for keywords,
  21. because that's the input to the computation.  But 
  22. there are many kinds of abstract documents, and many possible
  23. computations to yield concrete documents, and for many of
  24. these there will be other kinds of input requirements.
  25. It seems inelegant to support these by having the abstact
  26. document indicate its input requirements by returning a
  27. document with a special purpose tag (eg <ISINDEX>), since
  28. this will mean that every new kind of input will require a new
  29. tag in HTML.
  30.  
  31. Maybe this can be addressed in HTML2, by some process of negotiation
  32. between server (abstract document) and user/client.  e.g the document
  33. sends something back saying "I will give you a page of text but
  34. first send me at least one line of ascii".  If this is the
  35. right approach, then we need a means of describing data types and prompts.
  36. The negotiation might take several exchanges, or it might be done
  37. by having the server return a small program, something like a decision
  38. tree, to prompt the user for all meaningful values required for
  39. the input.
  40.  
  41. While I am on the topic, though, the protocol should be designed
  42. such that software agents on the client side can obtain documents
  43. without having to negotiate, if they have all the desired inputs
  44. ready to hand.  I don't want my user agent to have to parse X
  45. windows protocols in order to answer on by behalf.
  46.  
  47. Best wishes
  48.  
  49.